agent skills学习与实践
前言 Preface
记录以帮助我理解为什么需要, 以及设置了之后的好处.
简单理解
正常对话的token消耗是线性增加的.
// 第一次:
用户: 你好.
AI收到: 你好啊.
// 接着:
用户: 你好.
AI收到: 你好啊.
用户: 今天天气如何.
AI收到: 你好 + 你好啊 + 今天天气如何.
当对话上下文到达一定程度, AI会压缩一次之前的对话, 从而减少每次的token消耗.
而我理解设置的rules和skills的意义, 就是
- 省token, 我是穷鬼.
- 减少重复提需求.
比如我可设置
- rule: 忽略每次你好的打招呼
- skill: 应用我礼貌的人设
token消耗应该就变成了
用户: 你好.
AI收到: 你好啊.
用户: 今天天气如何.
AI收到: "你好, 你好啊."(忽略但知道我很礼貌) + 今天天气如何.
Skills
中英文差别
一般开发过程中基本都是用中文沟通, 但是问了GPT, 他给出的建议是用英文.
以下词在agent prompt中约定俗成.
| 英文关键词 | 模型理解 |
|---|---|
| MUST | 强制 |
| NEVER | 禁止 |
| ALWAYS | 必须执行 |
| ONLY | 限制范围 |
| DO NOT | 禁止 |
| REQUIRED | 必选 |
| BEFORE | 前置步骤 |
| AFTER | 后置步骤 |
Matt Pocock套餐
最近刷到Matt的工作流, 演讲很棒, 就是嘴有点碎. 这里学到了几个, 打算实践并加入自己的理解.
/grill-me/to-prd/to-issue/tdd
工作流如下:

我在图里的每个大模块都标注了结尾处可以新开agent对话框, 或者清除聊天历史, 以节省token消耗并保持context在较小的状态.
详细的skill内容就不贴了, 他已经全部开源了, 地址在这.
grill-me
---
name: grill-me
description: Interview the user relentlessly about a plan or
design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
这个skill很简单, 达成共识.
虽然现在已经有了PlanMode, 但是直接通过PlanMode得到的需求说明书也并没有那么细, 而且很容易拿到一篇大文, 我反正是很少全文细读.
拆成单问题的QA模式, 反而会让你每一步专注思考需求.
我目前主要使用还是Cursor, 我加了句 Use select UX to decide the answer., 更方便内置agent工具使用.
to-prd和to-issues
---
name: to-prd
description: Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
--
---
name: to-issues
description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
---
这两个可以放在一起写, 基本上就是把任务拆成标准格式 => 发到github => 作为开发前的指导需求文档.
对应到我们熟悉的敏捷开发里的工作里, to-prd得到的基本上就是feature/sprint级别的需求文档. to-issues得到的是下面的子任务.
比较值得提的点:
- 他用了
AFK(away from keyboard)和HITL(human-in-the-loop)标签来区分issue, 前者是AI立刻就可以开始写的, 后者是需要人为参与或者进一步提供指导信息的, 比如到supabase里设置点什么或者就某些问题进一步回答细节. - 拆issue时, 他强调了
纵向模式. 举个例子: 比如做一个登录注册模块. AI可能会拆成:
1. UI完成登录, 注册, 忘记密码页面
2. 登录, 注册, 忘记密码的接口和数据库
3. 联调, 测试.
4. ...
这是不好的横向模式, 因为你得到3完成才能测试和收到反馈. 好的拆分是
1. 前后端完成登录功能, 测试.
2. 前后端完成注册功能, 测试.
3. 前后端完成忘记密码, 测试.
4. 提组件优化.
TDD
---
name: tdd
description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
---
与其说tdd是个skill, 不说是一个设计理念, 都是围绕先写不通过的red测试 -> 代码 -> 所有red测试变green.
这个skill在之前大火的superpowers里也有.
我让GPT比较了一下两个版本的区别:
superpowers版 test-driven-development 更像 TDD 铁律手册。重点是:
- 必须先写测试
- 必须亲眼看到测试失败
- 测试没先失败就不算 TDD
- 先写了生产代码就应该删掉重来
- 强烈反对“测试后补”“这次先跳过”
- 对 mock 反模式有更细的配套文档
Matt Pocock版本的 /tdd 更像 真实项目里的 TDD 工作流。重点是:
- 测试要验证公共接口和用户可观察行为
- 不要测试实现细节、私有方法、内部协作者
- 先和用户确认接口变化、重要行为、测试优先级
- 一次只做一个 vertical slice:一个测试,一个实现
- 反对一次性写完所有测试再写实现
- refactor 时关注模块边界、deep modules、可测试性
一句话总结:
GitHub 版管的是:你有没有真的按 TDD 做。 /tdd 管的是:你写出来的测试是不是好测试,流程是不是适合真实项目。 我会建议以 /tdd 为主,吸收 GitHub 版的两条硬规则:必须先看到测试失败,以及 失败原因必须正确。
工作流实践
我用/grill-me -> /to-prd -> /to-issues -> /tdd干了一个跨境电商独立站的新项目, 全程都在用Cursor, 之前是composer2, 上周出现了composer2.5, 就切换了.
目前比较满意, issues全都在github上.
我基本上都是
- main切prd分支
- prd分支拆了之后切issues分支
- issues每一个提PR到prd分支, 看情况是自动合并还是我review再合并.
- prd上面的issues全部干完后, 我去终点关注test, 或者人工测功能. 然后继续在prd分支上酌情增加fix-issues.
从图里能看到, prd, issues各自都挂有分支, revert和进度管理都很方便.

模型的优劣
Composer对比GPT5.5和Opus4.7可谓是非常便宜了. 95%的情况Composer都能解决, 解决不了或者卡壳有点久的, 我换了模型还是会卡壳, 或者说多轮烧token, 我是$20/month穷鬼套餐, 遇到这种情况我基本就手动停了, 选择人工介入.
偶尔我会调用GPT5.5, 去review架构层面的东西. 或者在设计方案的阶段, 多个模型询问讨论做决策.
人为参与的点
- 我会重点review, prd拆issues的合理性, 确保每个issues是个小闭环, 起码是做完能自测.
- 当AI告诉我当前prd上已经全部做完了, 我会重点看test. Function或者Component这种自动化很全的我基本不看, 我只看playwright的E2E覆盖. 这在古法编程时代, 就相当于每个功能阶段性的产品展示了.
- 细节打磨, 比如form提交的warning提示词这种小细节, 整体页面的美感, 这些还是需要人去试了试再让AI继续improve.
其他碎碎念
UI层面目前依旧有风格很AI的问题, 我感觉这个问题应该会慢慢解决, 但不会一步到位.
我最近尝试了base44, 出来的UI已经很不AI了, 这是基于我的一句话泳衣跨境独立站生产的首页截图.

但是目前这个网站是前后端全部生成, 且不交付后端代码, 后期调整只能用他的平台token调教. 调整起来很烧钱.
长期来看, 我认为美感, AI是学不会的. 我很难想象AI怎么判断0.3s Ease In-Out动画和0.2s Linear动画哪个感觉更好, 如果只是抄, 不同的组合和风格, 感觉就不一样了.
AI让很多人开始觉得自己无所不能, 但是日子并没有好起来.